home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Windows Expert
/
Windows Expert.iso
/
windownt
/
perlnt.zip
/
README
< prev
next >
Wrap
Text File
|
1993-07-25
|
8KB
|
203 lines
Perl for NT
Copyright (c) 1993, Intergraph Corporation
You may distribute under the terms of either the GNU General Public
License or the Artistic License, as specified in the README file.
What follows is my port of Perl to NT. It is based on perl version
4.036 and supports most of the base language. Winsock support is
included. This port has been in use at Intergraph for little over a
month and has experienced no major crashes. Supplied with the source
patches is the test suite that we've been using to prevent
regressions. It is a modified version of the stock perl test suite,
using a different driver (testnt.cmd) and a different test file
extension (.nt instead of .t).
DISCLAIMER
This code is furnished on an as-is basis, with no support implied.
You are free to modify and redistribute the code to your hearts
content as long as you give credit where credit's due. I will gladly
accept bug reports via email, but will not commit to fixing any of
these bugs. I'll try, but my time is not my own...
END DISCLAIMER
This port is NOT a client of the POSIX sub-system for NT. If I had
used POSIX, then Perl would be pretty crippled, with no networking
support and no room to grow.
The main differences between a unix port of perl and the NT port are:
- No shell
- No fork
- System calls (syscall, fcntl, ioctl, etc. missing)
- No Set-uid bit
- Ownership (uid's, groups, etc.)
- No inodes in stat
- System info (stored in registry instead of /etc/*)
(For a quick synopsis on what is supported, check out the file
status.txt).
Having no shell makes wildcard expansion strange and it also causes
difficulties with perl scripts specified on the command line. Rather
than using the shell for wildcard expansion, it's better to use
globbing, which is done by running perlglob.exe. Later I'd like to
put globbing in the interpreter (it would be fairly easy with
FindFirstFile() and FindNextFile() doing the wildcard expansion) but I
didn't have time before making my release date.
Cmd.exe, NT's sorry excuse for a command interpreter, does not treat
quotes similarly to any unix shell. In particular, single quotes are
not treated as quotes, merely as individual characters. This is why I
ignore the argc and argv passed to main at program startup and
re-parse the command line.
Fork is not there (never had it, never will) and I haven't added an
explicit mechanism to create a process (although this should be
trivial using the usersub mechanism). The only way to create processes
at present are with back-ticks, open, or system. Since there is no way
to create an independent process, pipe is not really useful and is not
supported.
Readdir and friends aren't provided by NT, so I stole Diomidis
Spinellis idea for DOS and reworked it for NT. All the work is done in
opendir, which reads all the filenames in the opened directory into a
string table. Readdir and friends then get strings from this table.
It's not optimal, but it works for me.
Winsock only supports AF_INET sockets and those sockets only support
send and recv (no read or write). Socketpair is not there, since
winsock sockets are not inheritable (they have both a user and kernel
component). I had to fake out fdopen, since NT won't let you fdopen a
socket.
I also had to fake up a wrapper for strerror, since the one supplied
with NT doesn't know about socket error values. Since winsock routines
don't put their error values in errno, I put wrappers around the
socket calls to update errno if they had an error. The wrappers also
allow a lazy initialization of the socket system, only calling
WSAStartup() if a socket routine is called.
On an up note, this port includes support for access to the NT
registry database. All of the Registry API functions, with the
exception of RegNotifyChangeKeyValue (hey, I didn't name these things!
Talk to Dave "Mr Verbose" Cutler!) were implemented. For information
on what arguments they expect, read the file registry.txt. For
information on the actual API's see the Win32 API Reference help file,
included with the SDK for NT.
INSTALLATION
This distribution comes as four shar files (shell archives). I'm
assuming that you've got access to a unix system as well as an NT
system. Unless someone has ported /bin/sh or /bin/ksh to NT (MKS are
you listening?) as well as Larry Wall's patch program, you'll need
unix to get set up.
To set up a source tree that will build under NT, make a directory on
your unix system (we'll call it ~ntperl), copy the shar files into it,
and then run /bin/sh on each of the pieces. You should end up with a
directory that contains the files:
README
eg
lib
patches
registry.txt
regupdat
relnotes.txt
src
status.txt
t
usersubs.txt
Eg, lib, src, and t are directories. Patches is a file of context
diffs against the stock 4.036 source distribution of perl. The .txt
files are text files describing various parts of the port. regupdat is
a perl script that is used to update the NT registry database.
Now cd to a directory containing the vanilla source to perl (don't use
your unix source dir, as we're about to make some changes...). Type
the following command:
$ patch < ~ntperl/patches
This will go through and make the same modifications that I had to
make to get perl to run. Once this is complete, copy the contents of
~ntperl/src into your current directory. Now copy this tree to an NT
system and you should be able to build it by typing 'nmake'.
When you've successfully built perl, you should have two executables,
perl.exe and perlglob.exe. You can test the functionality of perl
using the files contained in the 't' directory that came with the NT
distribution. Type the command 'testnt' in that directory and the test
suite will run.
Once it looks like perl is running, decide where you'd like to keep
the executables, the library scripts, and any other scripts that you
might have and create a directory with the following sub directories:
bin
lib
eg
Copy the executables into bin, the lib directory from the NT
distribution into lib, and the eg directory from the NT distribution
into eg. Then run the perl script regupdat like so:
perl regupdat <drive>:<directory>
This will install a set of keys in your NT registry that perl will use
to locate the binaries and library files. If you want to use a
different key string than the one used in regupdat then you'll have to
make the appropriate changes in nt.c.
Included with this release is my version of the perl test suite. I
changed the driver name to testnt.cmd and the test extension from .t
to .nt. I did this so it would be easy for me to see what changes I
made from the unix test suite.
Also included is a version of find.pl named ntfind.pl. It's a quick
hack that works with NT. I don't claim that it's optimal. Not all of
the routines in lib have been modified to work with NT. As I modify
them for NT, I'll post them to comp.lang.perl. If someone beats me to
it, I'd appreciate a copy.
POSSIBLE FUTURE ENHANCEMENTS
I'd like to add a "spawn" facility that would allow a perl program to
start a process for two-way communications. Something like this:
pipe (MY_R, ITS_W);
pipe (ITS_R, MY_R);
&spawn ("foo.exe", "-v", ITS_R, ITS_W, ITS_W);
close(ITS_R);
close(ITS_W);
Where the ITS_* handles are stdin, stdout, and stderr for the spawned
process. I'd welcome a discussion on how this would best be
implemented. Also, once winsock sockets are inheritable, we'd be able
to implement socketpair and use it.
I'd also like to spif up the Registry access routines to return arrays
in the proper context.
It would sure be nice if we could pop up a dialog box...
Oh well, just dreaming. My manager has a list of stuff that will keep
me busy for the rest of the year. But in my COPIOUS spare time, I'll
keep looking at Perl for NT...
--------------------------------------------------------------------
Clark Williams
Software Development Tools
Intergraph Corporation
jcwillia@ingr.com